The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Large business-critical web applications are complex and experience highly varying load and usage patterns. These web applications are often expected to provide certain service guarantees in terms of response time, throughput, uptime, availability, etc. At times, it may be desirable make changes to a system, such as upgrading or modifying a configuration. However, before any change is made to a production system, extensive testing and validation should be performed in a test system. In order to be confident that a change will not cause problems (e.g., errors or performance issues) in the production system once that change is introduced into the production system, the web application in the test system should be exposed to an application workload that is very similar to the application workload that the web application in the production system would actually experience in a real world environment.
Previous testing approaches have been inadequate because none of these previous testing approaches reliably replicate a real production application workload in a test system in a transactionally consistent manner. Under one approach, test scenarios are generated manually and used in synthetic workloads. This approach often fails to reproduce the load patterns that would be experienced in an actual production environment.
According to another approach, application requests to a web application in a production system are programmatically captured and replayed against a web application in a test system, without any database-level synchronization. Although this approach can be useful for replicating a real production application workload, this approach does not provide adequate guarantee about the order of database transaction execution in the test system's database when the workload is replayed. For example, the occurrence of an error or performance issue observed in the production system may have depended on the order in which database transactions were executed in the production system. When the application workload is replayed against the web application in the test system, non-deterministic factors in the test system, such as timers, interrupts, network delays, CPU speeds, etc., may cause the execution order of database transactions in the test system to differ from the order in the production system.
For example, assume that, in the production system, the web application received two requests RQ1, and RQ2 that caused the web application to send three database commands to the database DBC1, DBC2 and DBC3 that were executed by the database in that order. When replayed, sending the same two requests RQ1 and RQ2 to the web application may cause those same three database commands to be sent to the database server, but in a different order (e.g. DBC2, DBC3 and DBC1). The order in which the database commands are executed may produce may have a significant effect both on performance of the system and on the outcome of the operations.
The possibility of producing outcomes during playback of a captured workload is problematic if a purpose for replaying the captured application workload against the test system is to diagnose or troubleshoot a problem observed in the production system. Thus, this approach is insufficient for accurately reproducing captured application workload in the test system.
What is needed is a solution that can replicate a real production application workload in a test system in a transactionally consistent manner. Such a solution should be implemented with underlying web application support so that the solution has little to no impact on existing web applications. Ideally, the solution should provide for transactionally consistent replay of an application workload without requiring changes to the database. The present invention fulfills these and other needs.